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1  Introduction 


1.1  Is  automatic  program  verification  important? 

P-ogram  verification  is  a  critical  problem  in  computer  science.  Many  believe  that  man¬ 
ual,  informal  verification  is  acceptably  reliable  and  more  practical  than  automatic  formal 
verification.  However,  verification  of  distributed  programs  is  difficult  to  achieve  manually. 

Consider  the  following  simple  distributed  algorithm.  Pj  and  P2  are  two  processes  that  are 
executed  on  a  processor.  They  share  a  common  variable  f,  and  each  has  a  local  variable 
yi,i  —  1,2  that  can  be  read  by  the  other  process.  We  assume  that  at  each  step  exactly 
one  process  is  active,  i.e.,  it  executes  the  current  statement.  Pi  and  P2  sham  a  common 
resource  (printer  or  disk)  and  the  algorithm  is  meant  to  guarantee  that  at  most  one  process 
uses  the  resource  at  a  given  time.  We  say  that  the  process  is  in  the  critical  section  when 
it  uses  the  resource.  L3  and  M3  are  the  critical  sections  for  Pi  and  P2,  respectively. 

The  reader  is  challenged  to  verify  whether  the  following  algorithm  satisfies  two  properties: 

1.  “Mutual  exclusion”  is  guaranteed:  it  is  never  true  that  Pi  is  at  P3  and  P2  is  at  M3. 

2.  Liveness  is  guaranteed:  always  if  P\  (P2)  is  at  La  (Mi)  (requesting  the  TesouTce), 
then  eventually  Pi  (P2)  will  be  at  P3  (M3)  (getting  the  resource). 


DECLARE 

t :  [0..1]; 

INITIALLY 

t  =  1; 

PROCESS  Pi 

DECLARE 

3/i  :  [0  -1]; 

INITIALLY 

Vi  =  0; 

L0  :  goto  L0;  (  {t  :=  1;  goto  L\\ } 
Lx  :  y\  :=  1; 

L2  '■  if  (2/2  =  0  V  t  =  0)  goto  L3; 
if  (y2  =  1  A  t  =  1)  goto  L2; 

critical  section  L3  :  t/i  :=  0;  goto  Lq', 

END 

II 

PROCESS  P2 

DECLARE  t/2  :  [0..1]; 

INITIALLY  t/2  =  0; 
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Mo  :  goto  M0;  |  {t  :=  0;  goto  Mi;  } 
:  y2  :=  1; 

M2  :  if  (t/i  =  0  V  t  =  1)  goto  M3; 
if  (yi  =  1  A  t  =  0)  goto  M2; 

critical  section  M3  :  y2  :=  0;  goto  Mo; 

END 


1.2  How  to  verify  it  automatically 

Program  verification  is  defined  as  follows:  given  an  implementation  A  and  a  specification 
t/>,  does  A  satisfy  \J)  ?  Putting  this  into  more  formal  terms,  in  the  most  general  case, 
program  verification  is  equivalent  to  the  problem  of  checking  if  L\  C  L2,  where  LX,L2  are 
two  languages  defined  by  Turing  machines.  Hence,  in  the  most  general  case  the  verification 
problem  is  undecidable. 

Programs,  however,  have  been  verified  manually.  Manual  verification  is  sometimes  mis¬ 
leading  and  almost  always  very  tedious,  especially  in  the  case  of  parallel  or  distributed 
programs.  Some  systems  designed  to  support  formal,  manual  verification  have  been  devel¬ 
oped  in  the  last  few  years.  For  example,  Crawford  and  Goldschlag  provide  an  interactive 
theorem  prover  to  support  the  verification  of  distributed  systems  ([CG87]).  Theorem 
provers  provide  only  a  partial  and  most  often  not  satisfactory  answer  to  the  problem. 

Taking  a  different  approach,  Clarke  et  al.  [CES83]  suggested  that  by  focusing  strictly 
on  finite  state  programs,  one  could  provide  a  fully  automatic  verifier  that  would  still  be 
applicable  to  such  domains  as  communcation  protocols  and  cicuit  design.  In  [CES83]  an 
algorithm  for  checking  a  finite  state  model  against  a  property  specified  by  Computation 
Tree  Logic  (CTL)  is  provided.  The  algorithm  is  linear  in  the  size  of  the  model  and  the 
property.  The  algorithm  was  implemented  [B86,  BC86],  and  was  proved  to  be  useful  for 
verifying  circuit  design.  However,  the  CTL  formalism  is  not  always  enough  to  express 
properties  of  distributed  systems  [L80,  EH86].  Linear  Temporal  Logic  (LTL),  on  the 
other  hand,  seems  to  provide  the  required  expressive  power  at  the  cost  of  having  a  model 
checking  problem,  which  is  NP-complete  [SC82]. 

Thus,  the  linear  temporal  logic  advocates  claim  to  have  the  required  expressive  power 
while  those  in  favor  of  branching  time  claim  to  be  “efficient”.  In  [LP85]  an  0{\M\2^) 
algorithm  for  checking  a  finite  state  model  M  against  a  linear  temporal  logic  formula  p  is 
described.  It  is  claimed  that  since  the  property  is  usually  small  and  the  worst  case  rarely 
happens,  the  algorithm  is  “practically  efficient.”  Branching  Time  “struck  back”  in  [EL85], 
where  it  was  shown  that  any  model  checking  algorithm  for  LTL  implies  an  algorithm  of 
the  same  complexity  for  CTL*,  the  extended  version  of  branching  time  temporal  logic, 
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which  subsumes  both  LTL  and  CTL. 


In  this  work,  we  provide  evidence  to  support  the  claim  that  model  checking  for  LTL  is 
“practically  efficient.” 

We  describe  two  implementations  of  a  linear  temporal  logic  model  checker.  One  is  based 
on  transforming  the  model  checking  problem  into  a  satisfiability  problem.  The  other 
checks  an  LTL  formula  for  a  finite  model  by  computing  the  cross-product  of  the  finite 
state  transition  graph  of  the  program  with  a  structure  containing  all  possible  models  for 
the  property.  We  experimented  with  a  set  of  mutual  exclusion  algorithms  and  tested 
safety  and  liveness  under  fairness  for  these  algorithms.  We  believe  that  the  measurements 
we  have  done  for  these  examples  provide  experimental  evidence  for  the  practicality  of 
model  checking  of  linear  temporal  logic  formulae. 

Section  2  provides  the  syntax  and  semantics  of  linear  temporal  logic.  Section  3  provides 
a  detailed  example  of  a  finite  state  concurrent  program  and  expresses  safety  and  liveness- 
under-fairness  properties  for  this  program,  in  LTL.  Both  implementations  are  based  on 
the  tableau  algorithm  described  in  Section  4.  Section  5  discusses  the  basic  ideas  behind 
the  two  different  model  checking  algorithms.  Section  6  provides  more  details  regarding 
the  implementations  and  experimental  results. 


2  Linear  temporal  logic 

A  temporal  logic  formula  is  defined  over  a  set  3>0  of  atomic  formulae,  using  the  boolean 
operftors  V  and  ->  and  the  temporal  operators  next  (Q)  and  until  ( U ).  A  model  for 
a  temporal  formula  p  is  an  infinite  sequence  of  states  a  :  s0,  sj,...,  and  a  mapping 
r  :  {si  |  i  >  0}  — >  2*°  assigning  to  each  state  s,  the  set  of  atomic  formulae  that  are  true 
at  this  state. 

<E>  denotes  the  set  of  all  temporal  formulae  that  are  inductively  constructed  from  $o  as 
follows: 

if  P  €  $o  then  P  G  $ 

if  p,  q  G  $  then  ->p  and  p  V  q  G  $ 

if  p,  q  G  $  then  Qp  G  $  and  p  Uq  €  $ 

For  a  given  model  a  and  a  temporal  formula  p,  we  say  that  (a,  j)  satisfies  p,  denoted  by 
(<7,  j)  f=  p,  if  p  is  evaluated  to  true  on  the  jth  state  of  a. 

Formally: 

(<7 ,j)  P,  for  P  €  iff  P  is  evaluated  to  true  in  Sj  by  the  mapping  r,  that  is,  if 

P  G  r(sj) 
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(<7,j)  t=  “T  iff  (<m)  £  P 

(<M)  h  P  V  q  iff  (cr,  j  )  (=  p  or  (cr,  j)  (=  q 

(<7,j)  N  Op  iff  (<m  +  i)  h  p 

(cr,  j)  (=  pffq  iff  there  exists  i  >  j  such  that  [a ,i)  )=  q  and  for  all  k,  j  <  k  <  i,  ( a,k )  (=  p 

We  use  the  following  operators  as  abbreviations: 

and:  p  A  q  =  _,(_,p  V  ~>q) 
implies:  p  — ♦  q  =  ->p  V  q 
equivalent:  p  =  q  =  (p  —>  q)  A  (q  — >  p) 

eventually:  Op  =  TUp,  ( <r,  j )  Op  if  for  some  i  >  j,  ( a ,  i)  |=  p. 
always:  Dp  =  ->0 ->p,  (cr,  j)  (=  Dp  if  for  all  f  >  j,  (<r,  i)  }=  p. 

A  model  a  satisfies  p  if  (cr,  0)  satisfies  p. 

A  formula  p  is  satisfiable  if  there  exists  a  model  that  satisfies  p. 

A  formula  p  is  valid  if  for  every  model  cr,  cr  satisfies  p.  Hence,  a  formula  p  is  valid  iff  ->p 
is  not  satisfiable. 

The  temporal  formalism  is  used  to  specify  properties  of  finite  state  programs.  A  program 
is  defined  as  the  set  of  all  possible  computations.  A  computation  of  a  given  program  is 
a  sequence  of  states,  starting  from  the  initial  state,  where  each  state  is  defined  by  an 
assignment  of  values  to  all  program  variables.  A  computation  can  be  viewed  as  a  model 
for  a  temporal  logic  formula.  A  program  satisfies  a  property  p,  if  for  every  computation 
<7  of  this  program,  a  satisfies  p. 

For  linear  temporal  logic,  the  model  checking  problem  is  stated  as  follows:  given  a  finite 
state  transition  graph  M  —  {N,E,r),  where  r  is  a  special  root  node  (the  initial  state), 
a  mapping  function  n  :  N  —>■  2*°  assigning  atomic  propositions  to  states,  and  a  linear 
temporal  logic  formula  p,  does  every  path  of  M  initiated  at  r  satisfy  p? 


3  Example 

To  demonstrate  the  terms  and  notation,  we  give  an  example  of  a  distributed  program  and 
some  properties  that  this  program  is  required  to  satisfy. 

We  distinguish  between  two  types  of  program  properties,  safety  and  liveness.  Safety 
properties  state  that  nothing  “bad”  happens  throughout  the  computation,  while  liveness 
properties  state  that  something  “good”  eventually  will  happen  during  the  computation. 
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We  assume  an  asynchronous  semantics,  meaning  that  the  set  of  all  program  computations 
consists  of  all  possible  interleavings  of  process  computations. 

Peterson’s  Mutual  Exclusion  Algorithm 


DECLARE 

t :  [0..1]; 

INITIALLY 

t  =  1; 

PROCESS  Px 

DECLARE 

y  1  :  [0-1]; 

INITIALLY 

if 

II 

o 

L0  :  goto  L0\  j  {yx  :=  1;  goto  Lx;  } 
L\  :  t  :=  1; 

L2  •  if  (j/2  =  0  V  t  =  0)  goto  Z/3; 
if  (y2  =  1  A  t  =  1)  goto  L2\ 

critical  section  Lj,  :  yx  :=  0;  goto  Lq\ 

END 


PROCESS  P2 

DECLARE  y2  :  [0..1]; 

INITIALLY  y2  =  0; 

M0  :  goto  M0;  |  {y2  :=  1;  goto  Mt; } 

Mi  :  t  :=  0; 

M2  :  if  (yi  =  0  V  t  =  1)  goto  M3; 
if  (yi  =  1  A  t  =  0)  goto  M2; 

critical  section  M3  :  y2  :=  0;  goto  Mo; 

END 


t  is  a  global  variable  and  t/i  and  y2  are  local  variables  of  Pi  and  P2,  respectively.  All 
variables  are  of  type  integer  with  range  [0..1|.  All  statements  appearing  under  the  same 
label  are  assumed  to  be  one  atomic  statement,  i.e.  nothing  is  interleaved  between  them. 
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Since  each  process  has  four  possible  locations  we  can  view  each  program  counter  as  a 
variable  with  range  [0. .3] .  To  describe  the  program  computations  we  transform  each 
program  variable  into  a  set  of  propositions,  standing  for  the  bit  representation  of  the 
variable.  We  use  f,  yx  and  y2  as  propositions  to  represent  the  corresponding  variables. 
Plo,  P2o  and  P2l  are  used  to  represent  the  program  counters  of  Pj  and  P2,  respectively. 
In  the  initial  state  of  the  program,  t  =  1,  yx  =  0,  y2  =  0  and  Px  and  P2  are  in  L0  and  M0, 
respectively.  Hence,  for  all  program  computations,  t  is  true  and  t/i,y2  )  P\ 05  Pll  5  P 20  and 
P2l  are  false  in  the  first  state  of  the  computation.  From  this  initial  state  there  are  four 
possible  transitions: 

1.  Pi  executes  the  statement  “goto  Z0’\  resulting  in  the  same  state. 

2.  Pi  executes  the  statement  “yi  :=  1;  goto  L\  \  resulting  in  a  state  where  pyi  and 
Pi0  hold  and  y2 ,  Pi , ,  P2o  and  P2l  are  false. 

3.  P2  executes  the  statement  “goto  M0" ,  resulting  in  no  change  in  state. 

4.  P2  executes  the  statement  “y2  :=  1;  goto  Mi”,  resulting  in  a  state  where  f,y2  and 
P2o  hold  and  y\,P\0,Pil  and  P2l  are  false. 

The  construction  of  the  global  transition  graph  of  the  program  proceeds  in  this  way.  Since 
the  number  of  variables  and  the  range  of  each  is  finite,  there  are  only  a  finite  number  of 
different  states. 

The  safety  property  that  we  want  to  check  for  this  algorithm  is  that  it  really  guarantees 
mutual  exclusion,  i.e.,  it  is  never  the  case  that  Px  is  in  P3  and  P2  is  in  M3  at  the  same 
time.  Hence  we  want  all  program  computations  to  satisfy 


□  -■(Pio  A  Pi,  A  P2o  A  P2, ) 

The  liveness  property  is  that  each  of  the  processes-if  it  is  not  idle  forever  (i.e.,  at  Lq  or 
Mo)-  eventually  gets  to  execute  its  critical  section.  Hence,  we  want  all  program  compu¬ 
tations  to  satisfy 


°{{Pio  A  -'Ph  v  ~‘P\0  A  Pu)  O(Pi0  A  Pi,)) 


and 


a((-P20  A  ~'P2 1  V  _,P2o  A  P2, )  — >  O(P20  A  P2, )) 


Often,  we  want  to  verify  that  the  program  satifies  these  properties  under  some  fairness 
condition,  to  exclude  those  executions  in  which  one  of  the  processes  is  not  active  from 
some  point  on  in  the  computation.  For  example,  we  may  want  to  consider  the  above 
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properties  under  the  assumption  that  each  process  executes  infinitely  many  transitions. 
It  is  rather  clear  that  Peterson’s  algorithm  above  does  not  satisfy  the  liveness  property  if 
we  do  not  assume  such  fairness.  To  specify  those  computations  that  satisfy  the  required 
fairness  condition,  we  use  an  additional  proposition.  The  proposition  p\  will  hold  only  in 
these  states  in  which  P,  is  active;  namely,  only  Pi  can  execute  a  transition  from  a  state  in 
which  pi  is  true.  Thus,  we  have  now  two  different  initial  states,  one  in  which  pi  holds  and 
one  in  which  -'p,  holds.  Each  of  these  states  has  four  possible  next  states,  resulting  from 
the  two  transitions  the  active  process  can  take  and  the  two  alternatives  for  the  next  active 
process.  To  specify  the  liveness  property  above,  under  fairness,  we  use  the  following: 

□(Op,  A  O(-ipi))  -*  □((P,0  A  -P,,  V  -Pl0  A  Pu)  -+  O(Pl0  A  Pu)) 


4  The  tableau  algorithm 

The  satisfiability  problem  for  temporal  logic  formulae  is  NP-complete.  In  the  worst  case, 
the  number  of  steps  needed  to  decide  if  a  given  formula  p  is  satisfiable  is  0( 2^).  The 
tableau  algorithm  for  checking  the  satisfiability  of  a  linear  temporal  formula  [PS81]  is 
aimed  at  avoiding  the  exponential  worst  case,  when  possible,  by  generating  only  those 
states  that  are  necessary.  The  algorithm  consists  of  two  parts: 

1.  Given  a  formula  p,  a  directed  graph  Mp  =  (Np,  Ep,  r)  is  constructed,  and  a  set  7 r(n) 
of  atomic  propositions  is  associated  with  each  node  n  in  N.  This  graph  is  “locally 
consistent”  in  the  sense  that  for  each  node  n,  the  set  of  formulae  tt(u)  is  consistent 
for  all  formulae  except  for  path  formulae  involving  O  and  U. 

2.  Checking  global  consistency:  for  each  node  n  E  Np  and  for  each  formula  Op,qUp  in 
7r(n),  check  if  there  exists  a  path  from  n  that  eventually  satisfies  q. 

In  the  following,  we  assume  (without  loss  of  generality)  that  all  paths  in  the  model  are 
infinite.  We  can  assume  that  the  formula  to  be  checked  is  of  the  form  p  A  OT. 


4.1  The  construction  part 

We  distinguish  between  two  types  of  formulae  called  a  and  fl  formulae. 

q  formulae  are  those  that  cm  be  expressed  by  a  conjunction  of  their  subformulae,  e.g., 
Op  =  p  A  0Op.  In  the  construction  procedure  an  a  formula  r  is  replaced  by  the  set  of  its 
subformulae,  denoted  a(r),  as  follows  : 
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r 

a(r) 

pAq 

{Pi9} 

□p 

{p,0°p} 

_,(pv?) 

O P ,  ~'<l} 

-‘{P  9) 

{Pi  ■’?} 

"’(Op) 

{□(-P)} 

-(□p) 

{O(-'p)} 

j3  formulae  are  those  that  can  be  expressed  as  a  disjunction  of  their  subformulae,  e.g., 
Op  =  p  V  OOp.  In  the  construction,  procedure  a  node  with  a  /?  formula  r  is  replaced 
by  two  nodes,  each  containing  one  of  the  sets  of  subformulae,  denoted  /?i (r),/?2(r)  and 
defined  as  follows: 


r 

ft(r) 

A(r) 

P  V  q 

M 

{9} 

p->  q 

Op} 

{9} 

p  =  q 

{Pi  9> 

{“’Pi  -l9} 

pUq 

{9} 

{p,0(p  ^9)} 

Op 

{P} 

{OOp} 

n(pA?) 

{"’Pi 

09} 

“’(P  =  9) 

{T)  9} 

{Pi  -*9} 

“■(P  Wfl) 

{d("’9)} 

{H^pA-i?)} 

To  describe  the  construction  algorithm,  we  define  for  a  set  of  formulae  <f> : 

The  set  next(<^)  is  the  set  of  formulae  that  must  be  true  in  a  successor  of  any  state  that 
satisfies  all  p  €  <t>- 


next (<f>)  =  {q  j  O?  G  <t>] 


The  set  basic(<^)  is  the  subset  of  <f>  that  uniquely  identifies  a  state  satisfying  all  p  £  <f>- 


basic(^>)  =  {p  |  p  E  4>  and  (p  is  atomic  or  p  =  O ?)} 

The  function  analyze(^),  provides  for  a  set  of  formulae  <f>,  a  set  5  of  sets  of  formulae 
resulting  from  repeated  applications  of  a,  0  rules  to  formulae  in  <f>.  The  function  analyze 
is  used  to  construct  Mp  =  ( Np ,  Ep),  as  follows: 

construct(p) 

start  with  root  r,  7r(r)  =  {p},  Np  =  {r},Ep  =  0. 

S  =analyze(;r(r)) 
for  <j>  €  5 

if  basic((£)  =  h  jic(7r(n))  for  some  n  €  Np 


8 


add  (r,  n)  to  Ep 
else 

add  a  new  node  n  to  Np,  with  7r(n)  = 
add  (r,  n)  to  Ep 
for  m  G  Np  a  leaf  in  (Np,  Ep) 

S  —  analyze(next(7r  ("»))) 
for  <}>  G  S 

if  basic(^)  =  basic(7r(n))  for  some  n  G  Np 
add  (m,  n)  to  Ep 
else 

add  a  new  node  n  to  Np,  with  7r(n)  = 
add  ( ni,n )  to  Z? 

end  construct 

The  function  analyze  is  formally  defined  as  follows  : 


analyze  ( 0o ) 


X  ■-  {(0o,l 

3)} 

for  G 

A'  with  <f>  yf  0 

X  :=  X 

-  {(<£,¥>)} 

if  p  €  4> 

if  p  is 

an  0  formula 

4>  := 

:  (<t>  -  {p})  U  {<7  | 

q  G  a(p)  and  q 

£  <P} 

9  :  = 

=  9  U  {p) 

=  X  u  {(d>,0>)} 

if  p  is 

a  /?  formula 

: 

=  {<t>-  {p})  u  {? 

1  <?  £  /?i(p)  and 

q&v) 

<t>2  ■ 

=  {4>-  {p})  u  {<7 

1  </  6  /?2(p)  and 

q&p) 

9  :  = 

=  u  {p} 

X  :=XKJ  {(*,,  *>),(&,  ¥>)} 

if  p  is  an  atomic  formula  or  p  —  Q)q 

<t>  '■=  <t>  -  {p} 

9  :=  9  u  {p} 

X:=X\J  {(<t>,9)} 

S:=  0 

for  (0,  <p)  G  X 

if  there  is  no  q,  -<q  G  <p 
S  :=  S  U  {0} 
return  (5) 

end  analyze 
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4.2  Checking  eventualities 


When  the  construction  of  the  structure  (Np,  Ep)  is  completed,  each  node  in  the  graph  is 
locally  consistent,  but  we  still  have  to  check  for  global  consistency.  That  is,  we  have  to 
check  that  each  node  satisfies  the  following  two  properties: 

1.  the  node  has  at  least  one  successor. 

2.  for  each  formula  of  the  form  Op  or  q  Up  in  the  set  of  formulae  7r(n)  of  a  node  n, 
there  exists  a  path  leading  from  n  to  a  node  m,  such  that  p  6  7r(m). 

Each  node  that  does  not  satisfy  these  two  properties  is  removed  from  the  graph.  The 
formula  p  is  satisfiable  if  and  only  if  the  remaining  graph  contains  the  root  node  r. 

[LP85]  shows  that  when  checking  temporal  consistency  it  is  enough  to  check  consistency 
in  the  strongly  connected  components  of  the  graph. 

A  strongly  connected  component  (SCC)  in  a  directed  graph  is  a  maximal  set  of  nodes  of 
the  graph  such  that  there  is  a  path  between  each  pair  of  nodes  in  the  set. 

We  say  that  a  SCC  ( N E ')  is  consistent  in  a  model  M,  if  for  every  n  e  N'  and  every 
Op,qUp  €  7r (n)  there  exists  m  €  N'  with  p  6  7r(m)?  and  if  N'  contains  a  single  node  n, 
then  there  exists  some  successor  of  n  in  M. 

check(Arp,  Ep)  checks  temporal  consistency  in  the  locally  consistent  model  Mp: 
check(ATp,  Ep ) 

find  strongly  connected  components  in  ( Np  Ep). 

For  G  a  leaf  SCC  in  (Np,  Ep) 
if  G  is  consistent 
stop 
else 

remove  G  from  (Np,  Ep) 
p  is  satisfiable  iff  r  €  Np 
end  check 

Ifp  is  satisfiable,  then  a  model  can  be  constructed  from  the  the  graph  (Np,  Ep).  For  every 
node  n  £  Np  and  every  Op  or  qUp  in  7 r(n)  we  know  that  there  exists  a  path  from  n  leading 
to  a  node  m  such  that  p  E  7r(m).  However,  we  have  to  construct  one  infinite  path,  starting 
from  root  such  that  for  all  nodes  along  the  path,  all  formulae  will  be  satisfied  along  this 
path.  The  following  procedure,  build_model,  defines  such  an  infinite  path.  Note  that  ; 
(the  semicolon)  here  denotes  concatenation. 

build_model(7Vp,  Ep) 

6(n)  denotes  the  ordered  list  of  successors  of  a  node  n. 
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n  :~  r 
a  n 
while  (true) 

m  :=  head  of  6(n) 
a  :=  o\m 

6(n)  :=  tail(<5(n));  m 
n  :=  m 

end  build_model 


The  tableau  algorithm  for  checking  satsifiability  of  a  temporal  formula  p  is  composed  of 
the  following  steps: 

1.  construct(p)  to  get  the  structure  Mp  =  ( NP,EP ) 

2.  check(iVp,  Ep) 

3.  if  r  e  Np 

p  is  satisfiable 
else 

~>p  is  valid 


In  the  worst  case,  the  size  of  Mp  is  0(2 M). 

5  The  satisfiability  approach  vs.  the  model  check¬ 
ing  approach 

Given  a  finite  state  program  A,  a  property  p  and  fairness  condition  F,  our  goal  is  to 
verify  whether  every  fair  (according  to  F)  execution  of  the  program  satisfies  p.  Two  basic 
approaches  to  this  problem  are  described  here.  One  is  to  construct  a  formula  4>(A,F,p) 
consisting  of  the  possible  transitions  that  can  be  executed  by  the  different  processes,  the 
fairness  condition  and  the  property  p,  such  that  -< <f>(A,F,p)  is  valid  iff  A  satisfies  p  under 
F.  The  other  approach  is  to  construct  the  transition  graph  for  the  program  A,  and  check 
if  F  — ►  p  is  satisfied  along  every  possible  execution  path  in  the  transition  graph. 


5.1  Verifying  by  checking  satisfiability 

We  are  given  a  program  A,  composed  of  n  processes  Pi,  P2, . . . ,  Pn,  a  property  p,  and 
fairness  condition  F;  we  wish  to  verify  that  any  possible  interleaving  execution  of  the 
processes  that  satisfies  F  satisfies  p. 

! 
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To  verify  that  A  satisfies  p  under  F: 


1.  For  a  given  algorithm  A ,  a  property  p  and  fairness  condition  F,  construct  the 
temporal  formula  <f>(A,F,p). 

2.  Use  the  tableau  algorithm  to  check  satisfiability  of  (f>(A,F,p ). 

3.  A  satisfies  p  under  F  if  and  only  if  the  tableau  algorithm  terminates  with  ->4>{A,  F,p)valid. 
4>(A ,  F,  p)  is  of  the  form 


<h  a,f,V)  — ■((/ a  □(  v  m.m  P)) 

t  =  l 

/  specifies  the  initial  state,  and  0(P ,)  specifies  the  transitions  that  can  be  executed  by 
process  P,.  If  <j>(A,  F,p)  is  satisfiable,  then  there  exists  a  model  whose  initial  state  satisfies 
/,  each  of  the  model  transitions  from  one  state  to  the  next  corresponds  to  one  of  the 
possible  processes  transitions  specified  by  0(P,),i  =  1,. . .  ,n,  and  the  model  satisfies  the 
fairness  condition  F ,  but  it  does  not  satisfy  p.  This  implies  that  this  model  describes  a 
fair  execution  of  the  program  that  does  not  satisfy  the  required  property;  hence,  A  does 
not  satisfy  p.  If  <j>(A,F,p)  is  not  satisfiable  it  means  that  ~i<j>{A,  F,p)  is  valid,  hence  any 
model  corresponding  to  a  program  execution  specified  by  I  A  □  (V”_10(Pi)))  that  is  a  fair 
execution  (i.e.,  satisfies  F)  must  also  satisfy  p,  hence  A  satisfies  p  under  F. 

To  be  able  to  specify  fairness,  we  use  for  each  process  a  proposition  p, ,  which  must  hold 
in  every  state  where  process  Pi  is  active.  The  general  form  of  0(P,),  is 

m 

Pi  A  p,(Pi)  A  (V  tk) 
k=l 

where  {tk  \  k  =  1,. . .  ,m}  stand  for  the  set  of  transitions  that  can  be  executed  by  P,  and 
p(Pt)  guarantees  that  when  P,  is  active  it  can  not  change  the  values  of  any  variable  that 
is  a  local  variable  of  another  process.  p(P,)  has  the  form 

A  A  (x  =  Ox) 

x  variable  of  p, 

Note  that  the  set  of  local  variables  of  a  process  include  the  program  counter  for  this 
process. 

Each  of  the  tm  is  specified  by  a  formula  that  is  a  conjunction  of  two  parts.  The  first 
part  specifies  the  current  state,  which  includes  the  program  counter  value  and  a  condition 
stating  some  values  of  some  variables.  The  second  part  specifies  changes  of  values  in  the 
next  state  resulting  from  executing  the  transition:  change  of  program  counter  and  change 
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of  variables  by  an  assignment  statement.  All  other  local  and  shared  variables  are  not 
changed. 

To  demonstrate  how  <f>(A,  F,p)  is  constructed,  we  now  define  the  parts  of  the  formula  for 
Peterson’s  mutual  exclusion  algorithm. 

I  -  -> Pi0  A  ->Pi,  A  ->P2 0  A  -'P2 1  A  t  A  ->yi  A  ->y2 

For  process  Pi : 


m(A)  =  (?/2  =  Oj/2)  A  (P2o  =  OA0)  A  (P2,  =  OA, ) 

0  =  -iPi0  A  -'Pi,  A 

(O^Ao  A  O^A,  A  (s/x  =  Oyi)  A  (t  =  OO  v 

OA0  a  O^A,  a  Oyi  a  (<  =  OO) 

0  —  Ao  A  —■Pi,  A 

O^Ao  a  OAi  a  (y  1  =  Oyi)  a  0( 

<3  =  -'Pi0  A  Pi,  A  (~>y2  V  ->0  A 

OAo  A  OA,  A  (yi  =  Oyi)  A  {t  =  OO 
0  =  -’Plo  A  Pi,  A  (y2  A  0  A 

O^Ao  A  OA,  A  (yi  =  Oyi)  A  (<  =  OO 
t\  =  Pi0  A  Pi,  A 

O^Ao  a  O^A,  a  O-’yi  a  (t  =  OO 


Hence 

0(A)  =  Pl  A  y(Px)  A  (t\  V  0  V  0  V  t\  V  0) 

For  process  P2: 


/*(A)  =  (yi  =  Oyi)  a  (A0  =  OAo)  a  (A,  =  OA,) 

0  =  _,P20  A  ^P2,  A 

(O^Ao  A  O^A,  a  (y2  =  Oya)  A  (<  =  OO  v 
OAo  a  O^A,  a  Oy2  a  (t  =  OO) 

t\  =  P2o  A  -P2,  A 

O-’Ao  a  OA,  a  (y2  =  Oy2)  a  0_i< 
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tj  =  -P2o  A  P2l  A  (-yx  V  0  A 

O^20  A  0^2,  A  (y2  =  O2)  A  (t  =  00 
<4  =  ->P2o  A  P2,  A  (j/i  A  ->f)  A 

O-^,,  A  0^2,  A  (y2  =  Oy2)  A  (/  =  OO 
^5  —  p2 o  A  P2l  A 

O~,p20  A  O-1^!  A  O-1^  a  (<  =  OO 


Hence 

0(P2)  =  p2  A  p(P2)  A  (4*  V  t\  V  V  f’  V  «’) 

A  fair  execution  is  an  execution  in  which  each  process  is  active  infinitely  often,  specified 
by  n(Opi  A  Op2). 

It  follows  that  in  order  to  check  safety  of  the  Peterson  mutual  exclusion  algorithm  under 
fairness,  we  have  to  check  satisfiability  of  the  formula 

-((/  A  □  (*(/>,)  V  0(P2)))  -  (0(Opi  A  Op2)  -»  □(~'(Pi0  A  Px,  A  P2o  A  P2l)))) 
and  to  check  liveness 

~'((I  A  D(^(Px)  V  9(P2)))  — *■ 

(□(Opx  A  Op.)  -  □((-|Pi0  A  Ptl  V  Pl0  A  ->Pij)  -  O(Pl0  A  Px,)))) 

Since  checking  satisfiability  is  exponential  in  the  size  of  the  formula  that  is  checked,  using 
the  formula  <t>(A,F,p)  to  check  if  A  satisfies  p  may  be,  in  the  worst  case,  exponential  in 
the  length  of  the  program  plus  the  size  of  the  property. 

5.2  Verifying  by  model  checking 

In  the  model  checking  approach,  the  transition  graph  of  the  program  is  constructed  and 
then  it  is  checked  to  determine  if  there  exists  a  path  in  the  graph  that  satisfies  -<(F  — ►  p) 

1.  Construct  the  global  transition  graph  ( S,T)a  for  the  program  A. 

2.  Use  construct(->(F  — >  p))  to  construct  a  structure  =  ( N,E ). 

3.  Cross  product  A/_,(p_p)  and  (S,  T)a  to  get  a  locally  consistent  structure,  denoted 
(V,  R)(a,f,p)  i  with  a  root  node  denoted  vq. 

4.  check((U,  R)(a,f,p)) 

5.  A  satisfies  p  under  F  if  and  only  if  v0  ^  V. 
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If  r0  €  V  after  check((V,  R)(a,f,p)),  then  the  remaining  structure  contains  a  path  corre¬ 
sponding  to  a  possible  execution  of  the  program  A,  and  this  path  satisfies  the  formula  at 
the  root  of  (.V,  that  is,  it  satisfies  ->(F  — *  p).  Hence,  there  exists  an  execution 

that  satisfies  F  but  does  not  satisfy  p.  This  implies  that  A  does  not  satisfy  p  under  F. 
If  r0  is  deleted  from  V\  then  there  does  not  exist  a  path  in  the  transition  graph  that 
satisfies  -'(F  — >  p),  hence  every  execution  of  the  program  A  that  satisfies  F  satisfies  p. 
This  implies  that  A  satisfies  p  under  F. 

5.2.1  Constructing  the  global  transition  graph 

The  global  transition  graph  consists  of  the  set  of  nodes  5  and  the  set  of  edges  T.  Each  s  € 
S'  stands  for  a  program  state  and  a  set  7r(s)  of  propositions  and  negations  of  propositions 
is  associated  with  it.  The  set  7r(s)  provides  the  value  of  the  program  variables  in  the  state 
■s.  by  the  corresponding  propositions.  In  each  state  s,  exactly  one  process  Pt  is  identified 
as  active,  by  setting  the  corresponding  p,  to  true  and  p3  for  all  j  ^  i  to  false.  The 
construction  of  the  graph  starts  with  a  special  root  state  s0  such  that  7r(so)  corresponds 
to  the  values  of  program  variables  at  the  initial  state,  so  has  n  successors,  where  successor 
i  corresponds  to  the  initial  state  with  process  i  active,  i.e.,  p,  is  true.  The  construction 
of  the  transition  graph  proceeds  by  generating  transitions  from  each  state,  according  to 
the  statements  that  can  be  executed  from  the  state  by  the  active  process,  and  creating 
states  corresponding  to  the  resulting  program  state  with  one  of  the  processes  being  the 
next  active  process.  Since  the  program  is  finite  state,  the  transition  graph  construction 
must  terminate. 

5.2.2  Cross  product  of  the  two  structures 

The  cross  product  procedure  is  defined  by  taking  those  pairs  (n,s),  n  £  N  and  s  G  S, 
which  are  consistent.  A  pair  ( n,s )  is  consistent  if  and  only  if  for  every  atomic  formula 
P.  at  most  one  of  P,  ->P  is  in  7r(n)  U  7r(s).  V  is  initialized  to  Vo  corresponding  to  the 
pair  (r.  s0),  that  is,  7r(f0)  =  w(r)  U  tt(so).  R  is  initialized  to  the  empty  set.  (V,  R)(a,f,p)  is 
constructed  by  cross_product. 

cross_product((Ar,  £,  r),  (5,  T,  s0)) 

start  with  root  u0,  tt(vo)  :=  7r(r)  U  7r(s0),  V  :=  {i>o},  E  :=  0 
for  v  €  V  a  leaf  in  (V,  R) 
for  m  €  N,  (n,  m)  6  E 
for  t  €  5, (s, t)  €  T 
if  ( m,t )  is  consistent 

if  for  some  u  €  V  basic(u)  =basic(7r(m))  U  7 r(<)) 
add  (v,  u )  to  R 
else 
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add  a  new  node  u  to  V  with  tt(u)  =  7r(m)  U  7r(f) 
add  (v,  u)  to  R 

end  cross_product 


6  Implementation  and  experimental  results 

6.1  Implementation  of  the  tableau  algorithm 

Several  issues  seemed  to  be  vital  to  an  efficient  implementation  of  the  tableau  algorithm. 

6.1.1  The  form  of  the  LTL  formula 

1.  Conjunctive  form  has  an  advantage  over  disjunctive  form.  A  disjunctive  form  of 
a  subformula  specifying  a  transition  in  the  program  is:  p,  A  c,  — ►  Otfv  where 
p,  and  cs  specify  the  current  program  counter  and  a  condition,  respectively  and  q,< 
specifies  the  next  state.  The  program  is  specified  by  the  conjunction  of  all  disjunctive 
formulae  specifying  transitions.  An  equivalent  specification  for  the  program  is  by 
disjunction  of  all  transitions  specified  in  conjunctive  form  by  pa  A  c,  A  ( j)q3<  (see  the 
formula  in  Section  5.1).  The  implementation  of  the  tableau  algorithm  was  faster  for 
the  conjunctive  form,  probably  because  of  the  priority  we  give  to  rules  applied  to  a 
formulae  (see  Section  6.1.3.). 

2.  Putting  the  “next”  operator  (O)  as  “low”  as  possible  turned  out  to  be  more  efficient 
than  an  equivalent  form  in  which  next  operators  appeared  before  A,  V  or  ->  operators. 

6.1.2  Representation  of  sets  of  formulae 

Each  node  in  the  constructed  graph  is  associated  with  a  set  of  formulae.  The  set  of  all 
possible  subformulae  of  the  formula  to  be  checked  is  computed  (the  size  of  the  set  is  at 
most  5|pj  for  a  formua  p)  and  the  formulae  are  numbered.  A  set  is  represented  by  an 
array  of  bits,  where  the  zth  bit  is  1  iff  the  zth  formula  is  in  the  set.  This  representation 
allows  operations  such  as  union,  checking  consistency  of  a  set,  checking  membership,  etc. 
to  be  performed  efficient'y  by  bit  operations. 

6.1.3  Application  of  a,/?  rules 

In  the  construction  procedure,  the  same  rule  may  be  applied  to  the  same  formula  many 
times.  To  avoid  some  of  this  duplication,  a  rules  should  have  prioprity  over  /?  rules,  as 
the  following  shows.  Consider  <f>  =  {41,42,  •••  >4fc},  a  set  of  formulae  where  41  is  an  a 
formula  and  42  is  a  /?  formula.  If  we  first  apply  the  /?  rules  to  42,  we  have  two  nodes 
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associated  with  4>\  =  {<71,  /3i(<72),  ■  ■  ■ ,  qk }  and  <f>2  =  {?i,  ■  ■  • ,  <7fc}-  Thus,  the  rules  for 

<71,(73 . qk  must  be  applied  at  least  twice.  Applying  the  a  rule  for  q\  in  <f>  will  result  in 

a  set  {q(<7i),<72,  •  •  •  ,<7fc}- 

To  try  to  minimize  duplicate  applications  of  the  same  rule  to  the  same  formula,  we 
construct,  in  a  preprocessing  procedure,  a  table  J1,  providing  the  results  of  repeated  ap¬ 
plications  of  a  rules  to  subformulae.  The  set  of  subformulae  CL(p)  is  computed.  For  each 
<7  6  CL(p),  the  set  a(<7)  or  the  sets  0i(q),  02(q)  resulting  from  applying  the  corresponding 
rule  for  <7  are  stored  in  T[q\,  the  entry  corresponding  to  q  in  the  table  T.  Then,  the  a 
closure  of  T  is  computed  by  repeatedly  applying  a  rules  to  each  set  <fi  in  the  entry  T[q ]  in 
the  table.  A  set  <b  is  a  closed  if  for  every  a  formula  q  £  (f>,a(q)  C  <p.  a  rules  are  applied 
to  sets  in  the  table  until  each  set  <f>  is  a  closed.  In  the  construction  algorithm,  a  rule  is 
applied  to  formula  q  in  a  set  <p  by  replacing  <f>  by  <f>  U  0  for  each  t/>  in  T[q\. 

6.1.4  Search  of  nodes  in  the  graph 

With  the  generation  of  a  set  <f>  the  graph  is  searched  to  find  if  there  exists  a  node  n 
such  that  basic(7r(n))  =  basic(<£).  To  enable  an  efficient  search  we  interpret  the  binary 
representation  of  a  set  7r(n)  as  a  number  that  is  used  as  a  unique  id  of  the  node  n.  The 
ids  are  hashed  (see  [K73])  into  a  table  of  size  K,  such  that  on  the  average  entry  i  in  the 
table  will  have  a  list  of  \NP\/K  nodes.  Hence,  to  search  the  graph  for  the  set  basic(<^>), 
we  search  the  nodes  in  the  entry  corresponding  to  basic(d>)  in  the  hash  table. 

6.2  Implementation  of  the  model  checker 

The  implementation  of  the  construction  of  the  global  transition  graph  uses  ideas  similar 
to  those  described  above.  States  are  represented  by  the  set  of  proposit’ons  and  negation 
of  propositions  that  hold  in  the  state.  When  the  cross  product  with  the  model  Mp  is 
computed  the  resulting  structure  is  composed  of  nodes  each  of  which  is  a  pair  of  pointers 
(PsiPn)  where  p„  is  pointer  to  a  state  in  the  global  transition  graph  and  pn  is  a  pointer  to 
a  node  in  the  model.  The  set  associated  with  (p,,pn)  is  tt(s)  U  7r(n)  . 


6.3  Experimental  results 

In  the  current  implementation  the  model  checking  approach  was  up  to  10  times  faster 
than  the  satisfiability  approach.  The  following  results  were  measured  on  a  SUN  4  for 
two  mutual  exclusion  algorithms  X\  and  X2  (see  Appendix)  X\  is  a  mutual  exclusion 
algorithm  for  n  processors  that  guarantees  safety  and  communal  liveness  but  not  liveness. 
Communal  liveness ,  in  this  case,  means  that  if  some  process  is  asking  to  use  the  resource, 
then  eventually  some  (not  necessarily  the  same)  process  will  get  to  execute  its  critical 
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section.  Algorithm  X 2  is  a  more  complicated  mutual  exclusion  algorithm.  It  guarantees 
safety  and  liveness  for  n  processors. 

Each  row  in  the  table  provides  execution  time  in  seconds  and  the  number  of  nodes  in 
the  locally  consistent  structure.  The  results  relate  to  the  verification  of  the  program 
composed  of  n  processes  of  algorithm  X\  or  >V2  (in  the  first  column)  when  checked  against 
the  property  in  the  second  column. 

Note  that  some  results  are  missing  for  the  model  checking  program.  This  is  because  the 
current  implementation  (to  be  corrected  in  the  near  future)  of  the  compiler  requires  a  lot 
of  manual  preparation. 


Algorithm 

Property 

Satis 

Nodes 

lability 

Time 

Model 

Nodes 

Checking 

Time 

'rf 

II 

£ 

Safety 

1514 

18.67 

1189 

5.61 

IKfflBBl 

Liveness 

2423 

78.94 

2566 

8.75 

!i££!LfcJifl 

Com  Liveness 

2171 

78.39 

3493 

55.08 

Xi,  n  =  5 

Safety 

6752 

113.37 

Xi,  n  =  5 

Liveness 

10289 

582.03 

X\ ,  Tl  =  5 

Com  Liveness 

9587 

560.51 

Xi,  n  =  6 

Safety 

28190 

698.46 

Xx,n  =  6 

Liveness 

91316 

8125.0 

X\,  n  =  6 

Com  Liveness 

79436 

7616.0 

X 2,  n  =  4 

Safety 

4598 

214.46 

3429 

50.49 

IlfflJgl 

6824 

885.02 

7541 

69.53 

X2,  n  =  5 

Safety 

23012 

2106.17 

* 

to 

II 

Cn 

Liveness 

73330 

19742.0 

7  Conclusions 


The  results  presented  here  indicate  that  model  checking  for  LTL  may  indeed  be  imple¬ 
mented  efficiently. 

In  [CS89],  a  distributed  implementation  of  the  satisfiability  algorithm,  provides  further 
improvement. 

Our  model  checker  provides  the  user  with 

•  The  expressive  power  of  Linear  Temporal  Logic. 

•  The  ability  to  check,  given  two  LTL  specifications,  whether  one  implies  the  other. 

•  Efficiency  comparable  to  the  CTL  model  checker. 
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Appendix 

Algorithm  Xx  for  2  processes 


DECLARE  y : [0  .  .  l]  ; 

INITIALLY  y=l ; 

PROCESS  PI 

DECLARE  tl :  [0  .  .  1]  ; 

INITIALLY  tl=0 ; 

L0  :  goto  L0;  I  {  tl  :=  0;  goto  LI;  } 

LI  :  if  (tl=0)  goto  L2; 

if  (tl=i)  goto  L3; 

L2  :  tl  y;  goto  LI; 

//  L3  -  critical  section 
L3  :  tl  y;  goto  LO; 

END 

I  I 


PROCESS  P2 

DECLARE  t2 : [0. . 1] ; 

INITIALLY  t2*0; 

MO  :  goto  MO;  I  {  t2  :*  0;  goto  Ml;  } 

Ml  :  if  (t2*0)  goto  M2; 

if  (t2=l)  goto  M3; 

M2  :  t2  y;  goto  Ml; 

//  M3  -  critical  section 
M3  :  t2  y;  goto  M0; 

END 
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Algorithm  X2  for  2  processes 


DECLARE  y : [0 . . 3] ; 

INITIALLY  y=0 ; 


PROCESS  PI 

DECLARE  rl: [0. .3]  ;  tl:  [0.  .1]  ; 
INITIALLY  rl=3 ;  t 1=0 ; 


L0  :  goto  L0;  I  {  tl  :=  1;  goto  LI;  } 

LI  :  if  (rl=3  “  (y=0  I  y=l))  goto  L2; 

if  (rl=3  '  " (y=0  I  y=l) )  goto  LI; 

if  (~(rl=3))  goto  L2; 

L2  :  if  (~(y=0)  '  “(y*l))  {rl:=:y;  goto  Ll;> 

if  (  (y=0)  |  (y«l))  {rl:=:y;  goto  L3;> 

//  L3  -  critical  section 

L3  :  -(  rl  :=  3;  tl:=0;  goto  L4;  } 

L4  :  if  (t2=l)  {y:=2;  goto  L0;} 
if  (t2=0)  {  goto  L5;} 

L5  :  if  (tl=l)  {y : =1 ;  goto  L0;} 
if  (tl=0)  {y:=0;  goto  L0;> 

END 


PROCESS  P2 

DECLARE  r2 : [0 . .3] ;  t2 : [0 . . 1]  ; 
INITIALLY  r2=3;  t2=0; 

M0  :  goto  M0;  |  {  t2  :=  1;  goto  Ml;  > 

Ml  :  if  (r2=3  "  (y=0  I  y=2))  goto  M2; 
if  (r2=3  "  ~ (y=0  I  y=2) )  goto  Ml; 
if  (~(r2=3))  goto  M2; 
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M2  :  if  (~(y=0)  *  ~(y=2))  {r2:=:y;  goto  Ml;} 
if  (  (y=0)  !  (y=2) )  {r2:=:y;  goto  M3;} 

//  M3  -  critical  section 

M3  :  {  r2  :=  3;  t2:=0;  goto  M4;  } 

M4  :  if  (t 1=1)  {y : =1 ;  goto  MO;} 
if  (tl=0)  {  goto  M5;} 

M5  :  if  (t2=l)  {y:=2;  goto  MO;} 
if  (t2=0)  {y:=0;  goto  MO;} 

END 
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